Doing the technology for the UDL project requires an interative developement style. Because it is so new to be using UDL concepts in science has not been obvious what technology is needed for this project. So our approach has been to build just enough tools to make make a working prototype of an Activity and then review the prototype. And then do that again.

First Prototype

The goal of our first prototype was simply to get an example of the content and format of an activity. This first prototype was built using html, javascript, flash, and java applets.
(insert a link or a screen shot?)
(link to description of the activity)
This gave us a concrete visualization of how the simple customizations could be controled by the user. In this first prototype these customizations where contrast, text size, and language.
These simple customizations we done using javascript to modify the CSS of the html page.
We explored using a flash animation to include a Zooming component in the activity. This flash animation allowed the user to start by seeing a macroscopic version of a scene, in this case a cloud, and then zoom in until the molecules of the cloud could be seen.
We embeded a Molecular Workbench model and a Drawing tool in the activity as as java applets. We used javascript to connect these 2 components together, so an image of Molecular Workbench model could be captured and then set as the background of the drawing tool. This way a user could annotate the captured image of the MW model.
Inorder to embed the MW model in the webpage it was first embedded in OTrunk and then the standard OTrunk Applet container was used to make it work as an Applet. (possibly insert picture here)

Take aways from first prototype

• Using html was an effective way to get a first prototype up and running. It allowed the content authors to start working on the content before we had an more advanced content system inplace. And then we were able to include interactive components in the activity using flash and java applets.
• Using flash for the zooming tool was effect for a prototype, but not a good long term solution. Making new zoom animations for different parts of the activity or different actvities would require working with a Flash programmer. And it was very likely that the activity author would want to tweak the zoom animation. So we decided to make the Zooming tool more generic so an author could control which images were used, and how they were zoomed.
• Using javascript to connect applets on a web page gave us another example of scripting 2 components in an activity. In previous concord project this scripting had been done in Pedagogica. Our plan for the UDL was to use a technology called OTrunk to layout the pages and connect together the components. The OTrunk model of laying out and connecting components is similar to how web pages and applets are handled in a browser. So this prototype gave us more infomation about how to build the OTrunk scripting so it would be easy to use.
• Now that we had MW embedded in OTrunk it was possible to make simple activities completely in OTrunk.
• Even though we were not planning to use Flash for the zoom tool, it became clear that flash support was important for effective UDL science activities. This came about as we discussed what should be added to this prototype activity. There needed to be a way to create and display animations of what was happening.

In the meantime...

While the first prototype was being built. We were working on support in OTrunk for multiple views of the same component.

One thing this would allow us to do is to start building a prototype of an authoring tool for these activities. Each component displayed in the activity would have 2 views an authoring view and runtime view. When the activity was viewed in authoring mode all of the components would show up in their authoring views. For example for the zoom tool, in its authoring view, there would be a user interface for adding, modifying, or deleting images from the zoom sequence and editing the region of the image being zoomed into.

A second thing this would allow us to do is to create activities that let the learner choose different representations of the same component. If the changes between the 2 views of the component are basic then these changes can be stored in the view configuration. In this case there are 2 configurations of a generic view for a particular component. For example in one configuration the color of text could be set to blue in another configuration the color of text could be set to red.

At this time the advisory board meeting happened and the planned structure of the UDL activities was changed.

Second Prototype

The second prototype was built entirerly in OTrunk. Its goal was to explore the changes to the planned structure of the UDL activities. These changes happened during and after the advisory board meeting. One change was to require the student to make a report of their work in the activity. So we made an OTrunk activity that allowed the user to choose components they had worked with in the activity and add those objects to a document they could edit. For example if the student collected a graph of temperature data in the activity, the student could then make a document that included that graph of temperature data. This functionality is sometimes called a report, portfolio, or labbook.

The second prototype also included support for an author to create multiple ways to ask the same question. This way at the same place in the activity one student might see one type of question while another student would see a different type of question. So the type of question could be tailored to needs of the student.

Take aways from the second prototype...

• the design of having multiple versions of the same question and then have a differen quesiton selected based on the students needs was daunting for the content authors to think about. The conculsion was to use scaffolding around the question instead of different versions of the question. The scaffolding would be ordered from easy to difficult. The level of the student would determine how much of the schaffolding he or she would see.

In the meantime...

During this time a new "snapshot" tool was created that generalized the way the drawing tool was combined with the MW in the first prototype. This snapshot tool could be added to any component in OTrunk. When the component was in a state the user wanted to remember they clicked a button to take a picture of that component, and then they could annotate the image.

Scripting was also added to the OTrunk system.

Third Prototype

The third prototype is being worked on right now. It takes the pieces from the second prototype and is combining them with content about friction. This prototype also includes a new use of Dynamica which is a physics engine CC had developed in the MAC project previously. This prototype includes the snapshot tool with the new dynamica component, and different scaffolding for various questions.